从软件架构视角剖析：手机当扫码枪小程序在智能盘点系统中的技术实践
做企业数字化这些年，我带团队交付过不少仓储和资产管理的项目。传统盘点方案里，那支笨重的工业扫码枪几乎是标配——两三千块一把，摔坏一个心疼半天，系统升级还得挨个刷固件。大概从2021年开始，客户们开始问：“能不能直接用员工自己的手机扫？反正是扫码，手机摄像头也不差。”这问题看似简单，真要做成稳定可靠的“智能盘点系统”，从软件架构上得脱层皮。
我们最近落地的那套面向连锁零售的盘点中台，端侧完全基于微信小程序实现“手机即扫码枪”，后台对接微服务集群。这里头不是套个 camera 组件就完事的，我更愿意把它看作一次端边云协同的轻量化架构实践。
先说端这一层。手机和小程序替代专用硬件，第一个坎就是扫码性能和弱网耐受。工业枪用的是激光头，毫秒级且不在乎光照；手机摄像头在仓库昏暗光线下容易糊。我们在小程序里没有用默认的 wx.scanCode，而是自己用 camera 上下文取帧，通过编译成 WASM 的 ZXing 分支做本地解码。这样不仅能批量识别（一屏多码），还能在断网时把原始码流和时间戳落进 IndexedDB，形成本地任务队列。这思路其实和以前枪里的嵌入式缓存一模一样，但容量从几条变成了几万条。记得有一次在华东某大仓做压力测试，地下室信号全无，盘点员拿着手机扫了四百多件，出仓联网后队列自动 flush，一条不丢。这种离线优先（Offline-First）的设计，是手机当枪的核心架构基石。
往后端看，系统不能把手机当成“可信专用终端”。它本质是个消费级设备，系统必须假设它随时会丢、会出错、会重复上报。我们的云端拆分了盘点任务调度、资产主数据、采集网关三个微服务。手机端通过 WebSocket 长连到网关，上报采用“设备指纹 动态 token”鉴权。海量的扫码事件进来，网关先扔进 Kafka 做削峰，后端消费者按任务 ID 做幂等落库。这里有个坑：有人喜欢用数据库唯一索引硬挡重复，但在高并发下会引发锁表，我们用 Redis 布隆过滤器预检，效果顺滑得多。
权限模型也得重构。专用枪是“设备即身份”，手机是“人兼设备”。我们走了 OAuth2.0 设备码流程，员工首次扫码绑定企业微信账号，后续每次会话签发短期 JWT。这样即使手机丢了，远程注销令牌即可，比停用一把枪敏捷太多。
实时大盘也是盘点的刚需。管理层想在后台看全国门店进度，这要求我们走 CQRS 模式，写模型走 Kafka 异步落库，读模型通过物化视图同步到 Elasticsearch。手机端每完成一个 SKU，进度条不是调接口查库，而是订阅同一个 WebSocket 频道的聚合事件。这样即便上万支“手机枪”同时开火，监控端依然流畅。
当然，工程落地总有琐碎的坑。比如小程序主包体积限制，WASM 解码库得拆到分包异步加载；再比如 Android 和 iOS 对相机自动对焦的策略差异，需要针对低端机做分辨率动态降级。这些细节在架构图上看不见，却决定了用户骂不骂娘。
回看这个项目，3000 多家门店砍掉了全部专用扫码硬件，单店盘点人力时间缩了 40%，IT 采购成本一年省下近百万。但比数字更有意思的是架构姿态的转变：我们不再把终端当成被固化的工具，而是把算力、容错和信任下沉到架构每一层去消化。手机当扫码枪，表面是硬件替代，底子是软件架构在轻终端时代的必然演进。
微信号：18581869297
